[レポート]ワークショップ「AWSセキュリティサービスを使用した脅威の検出と対応」に参加してきました。#SEC301

こんにちは。中村です。
本記事は　ワークショップ「Threat detection and response using AWS security services」 の参加レポートになります。

概要

Join AWS security experts for an immersive threat detection and response workshop using native security services to detect threats across different workloads. Learn about common threat types, how to detect them, and how to prioritize a response. This workshop simulates several security events across different resources and behaviors. Get hands-on in a provided sandbox environment to review and respond to findings from the simulated events. You must bring your laptop to participate.
［機械翻訳］
ネイティブセキュリティサービスを使用して異なるワークロード全体の脅威を検出する、没入型の脅威検出・対応ワークショップにAWSセキュリティエキスパートと共に参加しましょう。一般的な脅威の種類、その検出方法、対応の優先順位付け方法について学びます。このワークショップでは、異なるリソースと動作にわたる複数のセキュリティイベントをシミュレーションします。提供されたサンドボックス環境で、シミュレートされたイベントからの発見事項をレビューし対応する実践的な体験ができます。参加にはラップトップの持参が必要です。

スピーカー

• Ray Elkins, Senior Solutions Architect, Amazon Web Services
• Nicholas Jaeger, Principal, Security SA, AWS

レベル

• 300

内容

本セッションでは、ワークショップで利用するサービス概要をはじめに紹介いただき、ハンズオンという流れで進みました。
本ワークショップで主に利用したサービスは下記です。

• Amazon GuardDuty
• Amazon Detective
• AWS Security Hub

脅威を検知してから、評価や通知を行い、実際に対応する流れを確認しています。

またここで、各種サービスの概要を復習しておきます。

ワークショップ

本セッションでは、セクション４を中心としたハンズオンを行いました。
セクション４では、全7つの課題がありますが、私が取り組んだ課題は内3つとなります。
※テーマとなったAWSサービスの利用経験がない方はセクション０からスタートする案内がありました。

1. 認証情報が漏洩したシナリオ

EC2に割り当てられた一時的な認証情報を意図的に取得して、ローカルマシンからその認証情報を利用して、外部アクセスを試してみました。
不正アクセスをしているようでなんだかドキドキしました。
認証情報を取得したら、攻撃する人は地道にアクセス権限を確かめているんだろうなと。。。

さてここで、脅威検出のために複数のコマンドを実行しました。
次に、GuardDutyにて検知した脅威内容を確認してみます。

想定通り脅威が検出されました。

ここで、上記脅威が検出された時に自動で修復する方法を検討してみます。
このワークショップでは、事前にEventBridgeルール・Lambda関数・SNSトピックが作成されており、自動化修復が行われました。
EventBridgeでGuardDutyの脅威検出をトリガーとし、認証情報を削除するLambdaを起動することで自動修復するという流れです。

全ての脅威に対して、このような自動修復フローを構築することは現実的ではないとは思いますが、本課題を一例として他の脅威でも自動修復を作成できそうですね。

2. S3バケットの侵害への対応

課題用に既に検出されている下記の検出結果タイプについて確認していきました。

• Stealth:S3/ServerAccessLoggingDisabled
• Policy:S3/BucketBlockPublicAccessDisabled

特に後者の検出タイプは、開発環境においてよくみることがあります。
その多くが検証用に一時的にパブリックアクセスを許可するためのものでした。
しかし、意図した操作でなかった場合、データ漏洩のリスクが高まるため早急に対応が必要です。
通常、脅威検出したものについては、意図した操作かどうかを確認する必要があります。
GuardDutyで検出された脅威は既に起きた事象です。影響が大きくなる前に確認する運用とすることをお勧めします。

本課題では、脅威への対応として、手動にてアクセスログを有効化、パブリックアクセスをブロックする設定に変更する対応を実施しました。

合わせて、GuardDuty検出結果の「影響を受けるリソース」内のユーザ名について、アクセスキーを無効化する対応を実施しました。
今回は無効化を選択しましたが、使う必要がないアクセスキーは削除する方がより良いでしょう。

補足として、Config ルール「s3-bucket-logging-enabled」を活用し、非準拠となった時に修復を行う設定をすることで自動修復が可能になるとの案内もありました。

3. IAM認証情報の侵害への対応

この課題では、課題用に既に検出されている下記の検出結果タイプについて確認していきました。

• UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom

既知の悪意のあるIPアドレスで構成されている脅威のリストがあります。このリストに含まれるIPから接続された時に、上記脅威が検出されます。
そのため、高い確率で不正アクセスが行われている可能性があるということです。

本課題では、IAMロールの認証情報が不正に利用されていることがGuardDutyの調査結果から判明しました。
この対応として、IAMから該当のIAMロールのセッションを無効化します。
更なる被害を防止するためですね。

ここで注意が必要です。
セッションを無効にしたことでEC2のアプリで利用していた正常なアクセスも失敗してしまいます。
そのため、EC2インスタンスのアクセスキーをローテーションさせる必要があります。
単に再起動するだけではアクセスキーはローテーションされないため、明示的に停止→起動という手順を踏む必要があります。

課題では、EC2に接続してインスタンスメタデータからアクセスキーIDを取得し、検知した脅威のアクセスキーIDと異なっていることを確認しました。
異なっているということは、アクセスキーがローテーションされたということですね。

ここまでで修復が完了しました。
引き続き、関連した不審なアクセスがないかをDetectiveを利用して調査します。
今回はロールセッションに注目して調査を行いました。

Detectiveでの調査は情報量が多いため、初めて実施すると何をみて良いか分からないと感じると思います。
そんな方でも、今回はワークショップですので、気軽にポチポチ押して挙動を確認をすることができます。

また、Detectiveからでも侵害のあったIAMロールを特定することができるため、このフローにしたがってセッションを無効化するのも一つの方法です。
関連づけられたアクティビティを全て確認するのには気力が必要ですが、地道に調査していきましょう！

感想

今回は、実践的な調査を実施しました。
脅威の調査や修復といった作業は、日常の業務では頻繁に行うことではないので今回シミュレーションができてよかったです。
シミュレーションということで気軽に作業できるといった状況も良かったです。
簡単な脅威検出は1つ目のシナリオの用に自身でも再現できますが、込み入ったセキュリティ調査に関してはワークショップをぜひ活用したいものです！
また参加したいと思います！